Summary

Fixes #554 — the Debugger Modules panel showed an end address of -1 (and a ~2.3 GB size) for every module on macOS.

Root cause

LldbAdapter::GetModuleList() computed a module's size as max(section end) - base over all of the module's sections. On macOS this is fundamentally broken because dyld does not map system libraries as independent images — it groups the segments of different modules by type into the shared cache:

• all __TEXT segments are laid out together, all __DATA together, etc.;
• a single combined __LINKEDIT (~600 MB) is shared by every module in the cache.

So a module's own segments are scattered across gigabytes, and dozens of modules point at the same __LINKEDIT. Taking the max section end therefore spanned most of the shared cache, producing an absurd size that rendered as end = -1 in the UI.

Verified against /usr/bin/ls with the shared cache mapped — every module reported ~0x9xxxxxxx (~2.3 GB); one module even chained through to 0x22b1d0000.

Fix

Compute the extent from the header segment, keeping it to the range the module actually owns via two signals:

1. Clip at the next module's load base — a module owns [base, nextModuleBase), so segments that map into a foreign shared-cache region above the next module are dropped.
2. Stop at the first large inter-segment gap (64 MB) — bounds the single highest-based module, which has no next base to clip against. Observed intra-module scatter on macOS is ≥ ~240 MB, so 64 MB cleanly separates a module's own contiguous segments from the shared-cache jump while staying well above any inter-segment gap on Linux.

On Linux and for the main executable on macOS (contiguous segments), this yields the true full extent; for shared-cache dylibs it yields the contiguous __TEXT range, which is what image list/vmmap report as the module's range.

Verification

Simulated the exact algorithm against /usr/bin/ls (48 modules, shared cache mapped):

Notes

This is the targeted bug fix. The proper long-term representation — per-segment ranges and rwx permissions from the real memory map — is tracked under #96; once that lands, this heuristic can be replaced. A comment in the code explains why the end is the owned range and not a naive max-over-sections, to prevent a regression re-adding it.

🤖 Generated with Claude Code